Since KDE 4 development is in full swing with plans for a KDE 4.0
release sometime later this year, I thought I'd put together a
weekly piece entitled The Road to KDE 4. The idea is to
have a short overview of one or two of the features that show
progress in KDE 4. For my first issue, the goal is to show off some of the great SVG work that has taken place so far. Read on for the details...
Since many features are covered in personal blogs via the KDE Planet, I'll try to cover those that receive less public coverage, or need more public coverage.
The first thing I'd like to point out is that KDE 4 builds, installs, and runs well enough that I can test many of the ported KDE 3.x applications, and most of them are pretty stable. The real joys come when you look more closely at those improvements that are afforded by the changes in the base technologies. Today, I'll talk about one of the eyecandy features provided by Qt 4: SVG rendering in applications.
There are many other KDE applications reaping the benefits of SVG drawing to make them more pleasing, and more scalable. Check out some of these posts:
Today I'm going to focus on a handful of apps, providing before and after screenshots to compare the KDE 4 development version (pre-alpha stuff) to the existing KDE 3.5.5 equivalents.
To begin, I'll look at the KDE System Guard, a useful utility packed into KDE that you can pull up as 'ksysguard'. It does all sorts of neat things like display charts of memory and CPU usage, and a process table (also accessible via the Ctrl-Esc keyboard shortcut).
Here's how it looked in KDE 3.5.5:
And now, in the KDE 4 development series (the lines are antialiased, the graphs are translucent and the backgrounds are SVG):
As you can see, it is visually much improved from its current and very functional form.
Next we'll look at some of the diversions shipped in the kdegames package. KAtomic is a puzzle game. It's fun, semi-educational, and could definitely have used an image overhaul. Here it is in it's spartan KDE 3.5.5 glory:
And now, with much improved oxygen-style graphics in the development series:
KMahjongg ships in the kdegames package, and is a staple of puzzle gaming. Here it is from KDE 3.5.5 looking like a game that escaped from the
Best of Windows Entertainment Pack:
And now, with a much-improved SVG-powered tileset in the
development series:
And last but not least, is one of the more frequently used parts of KDE: the "Run Command" dialog (Alt-F2). Previously this:
Now, thanks to desktop interface guru Aaron Seigo, it's a SVG themable, really slick element of the Plasma desktop. Still a work in progress, but you'll get the idea from this screenshot.
Until next time folks, when I reveal yet another KDE 4 feature under development. Cheers.
Comments
Why browse and tag your Files when you can play a nice round mahjong :)
Its already usable by secretaries now :) And they will be more productive !
Lets add more games :) kate/konqueror/okular/plasma , who needs this :>>
seriously : The ksysguard and mahjong look awsome , alt-f2 and atomic need much more work/love :)
Well, krunner (the new run dialog) is only a few weeks old... it works well enough, and we'll probably see it mature in the next few weeks (as it's really a very simple app anyway).
As for KAtomic, it'll get some love too... the SVG graphics are just preliminary at this point anyway. Notice how there's still shadows under the arrows there... it's because the arrows are just stolen toolbar icons so far.
The beauty of SVG though is that it can be very easily changed, themed, etc. without having to do much work (IE: no recompilations to fix a pixel).
yes, krunner is about 4-5 hours of work altogether so far including me sitting down and thinking about what i wanted it to do.. =)
i really liked the music when atomic came out on the Amiga.
Can we perhaps somehow *ask* the copyright holders if we can have the music ?!?!?
that would be soo great
scratch your itch :-)
I'm sure the KDE game devs would be very grateful if you would. Half the problem is getting in contact with the people authorized to make such a decision.
as kde gets more and more animations - What about Video-Shots , instead of Screenshots? Would be a nice addition for KSnapshot !
Now, that's an _excellent_ idea. Talk about innovation!
Try wink
Oh wow, the new KMahJongg looks almost as good as the Gnome version....
I am excited about KDE 4 though!
From the looks of it, they took the svgs from the gnome version. Im sure it will be improved further later on. I hope they make the two compatible though, so the two apps can continue to borrow tile sets from each other.
Actually the SVG tilesets used by Kmahjongg (and shared with KShisen) in KDE4 are original, contributed by Raquel Ravanini and Robert Buchholz. Due to our needs (angle switching) we needed to compose tile backgrounds and faces at runtime and have all elements separated in the SVG file, so these were drawn specifically to match what our games needed.
I admit that the current GNOME Mahjongg looks better than the current KDE 3.5.5 Mahjongg. However, the KDE 4 Mahjonng with the SVG graphics makes the GNOME version look cartoonish. Take some screen clips, and compare the three side by side.
After seeing some of this stuff, I now believe that KDE 4 is going to be stunningly beautiful.
nice thing is, the KDE version can change the orientation of the tiles with the g and h keys (if i'm not mistaken), and do that incredibly fast.
...the question is: Does it render quickly enough, not to flicker, when the system is under load and you're resizing the window (without keeping a (in "advance" filled) cache, eating a large amount of memory)? Or do the minimal GPU requirements match Vista?
Hopefully there's at least a compatibility mode for people who don't want exchange a fast working system for 'bells and whistles' or feel forced to buy new hardware (or to choose another desktop)...
The minicli above looks much better.
SVG's can take a while to rerender when you resize the window.
I was thinking for ksysguard to just resize the cached image, with a, say, 500ms timer to rerender the svg once the user stops resizing. But I didn't think it was worth the effort. If people do care, then I could perhaps do that.
(At the moment it rerenders as you resize. This means it feels jerky as you resize.)
That (at X, Y, Z size prerendered) bitmaps of the SVG's would be scaled down (at best on GPU level) was the premise I had in mind. Just that you quickly run into the problem of large cache sizes, which are a PITA.
Hopefully everyone is keeping this in mind (rather a lot of small elements that get reused and are already cached, than each application "its" fat svg costume; prerendering and caching, incl. storing the cache on disk: Nothing is more annoying than having slow starting applications, because of svg elements being rendered - large bitmap loading might be slower though; aggregating multiple svg's in one file avoids seek times,...)
Scalable graphics are nice at development time, but at runtime with users noticing artifacts and slowdowns in milliseconds, there's no way to go without very smart bitmap caching.
>(At the moment it rerenders as you resize. This means it feels jerky as you resize.)
At the moment it doesn't matter. A 4.0 release with such a "feature" would be catastrophic.
Remains the question, why Xorg doesn't care about application provided vector graphics - especially when you think about remote desktops. But that's way off topic, I suppose. :)
xorg just lacks good SVG rendering acceleration. we'll have to wait a (long) while for that... it would solve the speed problem, tough.
btw here it's definitely not jerky, but outright slow. it takes approx a sec to resize the window. but imho that's better than being jerky, tough, it takes some time but doesn't flicker or something.
> btw here it's definitely not jerky, but outright slow. it takes approx a sec to resize the window. but imho that's better than being jerky, tough, it takes some time but doesn't flicker or something.
Well, even if Qt 4 does draw off-screen, avoiding flickering, and isn't as retard...err...90's with regards to threading as Qt 3.x - any user interface "stalling" is nowadays outright unacceptable, would be a very bad user experience and bad PR for KDE 4. Such "little" things count more, than a long feature list.
> SVG's can take a while to rerender when you resize the window.
That would totally s**k.
I have a similar problem with Beryl, I'm back to outline resizing because Beryl is too slow with resizes.
Would it be possible to precompile the SVG into something more efficient? This could be done on the fly when a SVG is changed.
Microsoft seams to be something something like that with their XAML format (see http://en.wikipedia.org/wiki/Extensible_Application_Markup_Language). They compile it into BAML before it's used as resource. Like SVG, their XAML files can be created by a designer and used 1-on-1 by developers as application interface.
Parsing the XML is not the problem with resizing. I presume that Qt is sensible enough to only do that when the SVG is first loaded (although processing large quantities of XML is expensive to do and can adversely affect startup times which is presumably why Microsoft compiles XAML into another binary format).
The expensive part when resizing (I think) is drawing the complex polygons which were described by the SVG file and then filling them with all manner of gradients and transparencies.
Qt 4.3 includes some hefty improvements for rendering complex polygons, including making better use of OpenGL to cut down some of the work considerably. Zack Rusin's blog provides more details.
Qt reads in the xml and makes a kind of dom tree.
A strategy I used in scaling images like that before was using a bitmap of, say, max 200 pixels wide and scaling that up to give instantaneous feedback while scaling. A background thread would then render the svg in its full resolution and when its done it will be shown on screen.
This gives direct results and smooth rescaling. And while things move the human eye can't discern details anyway so if it takes a maximum of 200msec before the final svg is finally rendered you would totally NOT notice. If it took half a second you'd just see some updating, but you'd have to look really good to see what it was.
Lets see if we can get that into kdelibs somehow ;)
You want to know, but talk like you already know the answer (of course the answer is negative).
Also, next time someone complains about "bells and whistles", they should be sent straight back to the command line. Or install Windows 95 if they get that running.
Sorry, technical Darwinism is cruel.
Are you serious?
I'm not convinced krunner really needs any options. The current run command dialog has:
(i) run as a different user;
(ii) run as root.
(iii) run in terminal
(iv) run with different priority
(v) run with realtime scheduling
(i) is practically never done, and (ii) should never have to be. Any app that requires root privs should launch with them. (iii) obviously doesn't need to be there; if you want it to run in the terminal, then run it in one. (iv) and (v) are [rarely-used] power-user features and I don't think they should be there.
You use the word "should" three times. Developers: Please don't remove useful functionality based on how things "should" be!
Should not the "Cancel" button be removed? If the user does not intend to run a program, she should not press Alt-F2 in the first place.
That said, you do have a point that these options are probably rarely used, but that is IMHO already taken care of by hiding them under the "Options" button.
I'm using each of the enumerated options no more than 4-5 times a year. I'm using [alt]+[f2] about 20 times a day *without* any options. That means, 99.7% of occurrences when ${me} is using [alt]+[f2] I'm happy with the most simplistic "dialog" you can ever imagine (I don't even notice the "Options >>", "Run" and "Cancel" buttons then -- I just hit [enter]... )
Do I therefore want the listed features go away? No, most certainly NO!, 'cause I still need and *use* one of them once a month or so....
Would I strongly oppose any move to scrap the "Options >>" button (or an obvious way to invoke a more feature-rich krunner) altogether? Hell, YES!, you can bet on that for sure.
Those new SVG capabilities do open a whole new universe of implementing lots of eyecandy as well as new usability features. (Though I expect no-one, developers or artists, to be able to find the correct balance in his first approach playing with his new SVG tools... be prepared to see also quite some creations that you do only like a week or a month and then be saturated...) I think this is a premier opportunity for KDE to draw a whole new layer of artists into its ranks, who will be excited to see what huge play- and creation-ground these things do offer to them.
Indeed, as we are KDE and not GNOME
I like power user options to be accessible, not to be completely hidden from the (not so powerful) user.
Forgot to mention that I *did* notice the (very unobtrusive) "Options" link (not a button) in the screenshot of the new krunner above, and I'm happy to see it is still there.
I just did want to let a voice be heared that opposes these "fascist GUI purgers" (Linus Torvalds' expression) who do want to dictate users what they ought to have and what they ought to forego.
Of course, I'm not opposed to cleanse "cluttered" and "bloated" UI elements from the default views -- but please let me continue to get easy access to all of them should I so desire.
That's a bit of a ridiculous argument. "Should" is simply an imperative, and even if you don't think or know it, it's used ALL the time. Should all our window decorations be red? No, they shouldn't.
Don't get me wrong, I absolutely adore the configurability and extensibility of KDE, and I in no way want that to change. And re-organising things is certainly not that. And none of what you've said addresses the point.
You should *never* have to use the "run as root" option, and in fact that's even dangerous to new users. If the "run as new user" is actually being used then we should find a way to incorporate that, but there's no reason for why it should be in the very basic "run application" dialogue.
"You should *never* have to use the "run as root" option, and in fact that's even dangerous to new users. If the "run as new user" is actually being used then we should find a way to incorporate that, but there's no reason for why it should be in the very basic "run application" dialogue."
No. You simply don't see a reason to use it, while I can imagine a lot of occasions in which I want to run application X sometimes as root, sometimes not, and *I* want to decide it (not the application).
Who are you to decide what I should have and don't have to use?
+1
I hate "facist GUI purgers" too.
I hate people that dictate how I should use my computer and what I should do with it. I want to decide myself!
I hate GUIs that requires a registry editor to access all features because someone decided for me. (Gnome / Windows)
purging GUIs is as stupid as swapping Ok/Cancel buttons to differenciate from windows forgetting in the meantime that some users may required to run both windows and gnome and thus leading to many mistakes.
This to illustrate that when the programmer decides for the end-user he can never think to the whole impact of his decision and thus, this always lead to reduced ergonomy.
Emacs succeeded because it was flexible and feature rich. Think about that when removing features.
-1
By all means, no one dictates how you should use Linux. That's freedom for you ;-). If you want to decide for *yourself* then write your own software.
"I hate GUIs that requires a registry editor..."
Lots of KDE functionality is hidden in rc files. Are you going to hate KDE for that too?
"as stupid as swapping Ok/Cancel"
I think you'll find that swapping the OK/Cancel buttons wasn't done to be different from Windows, so stop with the outlandish, uninformed claims.
As for "when the programmer decides for the end-user" -- the programmer is always deciding for the end user when they write their program. Simple as. You have to draw the line somewhere.
I'd argue that the original request of removing those arcane options is warranted. If you want a more powerful way of executing applications you're most probably a power user that has a shell open and can do that for yourself. If not, a replacement could be optional.
With that said, I think the new options is unobtrusive enough to not matter. I definitely agree that the current dialog needs some TLC, and the new one looks sweet.
>If you want a more powerful way of executing applications you're most probably a power user
"GUI fascists" see users black and white , i. e. either completely stupid and scared or so advanced as to work with registry/command line. But you excluded! a whole lot of users who are not at all afraid about extra 30 options in configuration dialogs, but either cannot edit registries/cmdline or have no time to find out what/where/how to do it.
As for swapping the OK/Cancel buttons - nobody thought that you saved little mouse movement, but overloaded my user brain with thinking much more about what button to press, as users you know have habits, and you broke them. It seems to me that some stupid manager/designer decided this, and other people don't see, that king is naked..
well, it is really a lot easier to press ok in GNOME, when one gets acustomed to it.
The problem is, if you need to ask, defaylt should be Cancel, not OK :)
people may switch back to Windows long before the time will come,
they would become accustomed to reversed buttons.
I think Gnome is optimized only for corporate users, home users are ignored.
It is hilarious how commenters accuse people of "GUI fascists" while at the same time making incredibly harsh generalisations themselves.
There are tradeoffs. Sometimes less is more and sometimes less is just less. Gnome doesn't always get things right but no one ever claimed KDE was perfect.
Gnome is aiming for a different audience, and they make it much harder to get lost or to shoot yourself in the foot but the downside is things are far less configurable at first. KDE on the other hand makes many things configurable, probably more than most users need but with time it should become clearer which options can be streamlined or better presented at the right time and place. Both
Gnome and KDE will continue to improve and bounce in and out from the happy medium.
I wont go into the button order thing but it isn't an arbitrary decision and Apple did it long before Gnome. QT 4.2 makes it even easier for developers to integrate applications with whichever button order users prefer, hopefully GTK will also improve the work they have done so far to allow alternative button ordering.
I think the best way to address mentioned tradeoffs is to make in applications menu two choices "Options" and "Advanced Options"(which would have "set all to default" button). Clueless users won't go to "Advanced options" . Those who shooted themselves in the foot will just press "set all default" in "advanced options".
"Emacs succeeded because it was flexible and feature rich."
Yes and no. Read about Emacs
http://www.jwz.org/doc/lemacs.html
Emacs was forked and replaced by the more user friendly X-Emacs which succeeded because it was more user friendly and gave more people what they wanted (although you could chose to interpret that user friendliness as "more features" if you wanted).
:P
Dont underestimate the power of broader appeal and I think the parent post was pointing at that with better defaults and asking the right questions in the right places for less options would be needed. If the user was prompted for root passwords when needed then wouldn't it be possible to combine both run as root and run as other user?
All very nice and vague until you back up an actual use-case. Which X application do you need to run as root; and, do you know of a user that doesn't know about kdesu who runs these applications as root?
If there's a case, then tell me; I'd genuinely like to know. I actually started off just wondering if we really do need them. See my first post; I only said that I'm not yet convinced. I think the argument raised here that running an application as a different user (with the example of kmail) is a valid use-case, and perhaps makes the option quite worthy.
> Who are you to decide what I should have and don't have to use?
I'm not a KDE developer but, believe it or not, users can still have opinions on how an application should function. There's nothing controversial in this; see bugs.kde.org -- they're all cases of users proposing that an application doesn't function in the appropriate way. Do you think that's unreasonable?
There are cases where the application does not have the ability to prompt the user for a root password.
Is that the fault of the program? Should it be fixed? Is it really the user's fault that the programmers didn't implement this?
Answer: No, no and no.
Just because a user want to run a program as root doesn't mean the program always should run in root. There for its not a good idea for the program to automatically prompt the user.
Lets say I wanted to edit a text file. I don't want to open the file using kate or kwrite, as with a different user as it could take longer to open and if they are not configured it could create a backup file which I don't want. I want to use a console based text editor, and the file I need to edit isn't owned by me.
How do I do this?
without the options button I'm forced to start konsole, run su, run nano /path/to/file
with the options button? I type in: nano /path/to/file
check the run as different user
check run in terminal window
How often does one have to do this, perhaps not too often. But that doesn't mean they shouldn't have that ability. having that ability doesn't clutter up anything nor does it make it run slower or not do a good job at what it does.
> There are cases where the application does not have the ability to prompt the user for a root password.
> Is that the fault of the program? Should it be fixed? Is it really the user's fault that the programmers didn't implement this?
Very wrong, in fact. It's the distribution's fault if it ships with an application that requires root privs and yet still doesn't open with kdesu or gksu when being launched.
> Lets say I wanted to edit a text file. I don't want to open the file using kate or kwrite, as with a different user as it could take longer to open and if they are not configured it could create a backup file which I don't want. I want to use a console based text editor, and the file I need to edit isn't owned by me.
> How do I do this?
> without the options button I'm forced to start konsole, run su, run nano /path/to/file
Again, wrong. Right-click -> edit as root is a very valid option. See my other post for why I think this is the method that a new user would choose.
But in that case, the RMB gets duplicated entries for each app able to edit that kind of file. That causes uglyness.
Exactly, good point.
And not to mention you have to open Konqueror, navigate to /path/to/ and then RMB on the file. Which is rather different to the whole concept of using alt+f2 in the first place.
So you check if the user can write to the file.
If they can, you only need 'edit'
If they can't, you only need 'edit as root'
(and you could then name just them both 'edit')
>Very wrong, in fact. It's the distribution's fault if it ships with an
>application that requires root privs and yet still doesn't open with kdesu or
>gksu when being launched.
No, it's you thats wrong. This is not a thing for the distribution or developers to decide, it's for the user to decide if root privs is needed when running the application. You use it for applications you sometimes run as root, but mostly don't. The deleopers or distributions have no way to decide if the user want's it with kdsu or not.
In a menu they can do it, like with kfm(Konqi in filamnager mode) where you have one entry for normal and one for starting it as root. But this does not fit in the concept and use of alt+F2. The whole point is to *not* use a menu and *not* right clik on files etc.
>>I'm not convinced krunner really needs any options.
Then stay away from the [options] button in krunner :o)
(i) i use that to start the e-mail application of my SO
(ii) i use that one to start an application that i otherwise could use as user as well, but want to run it as root for now, or for non-kde-applications that need to be run as root but do not provide options to become root
(iii) nice for people who need to run something in a terminal but don't know how to start one (as linux becomes more popular, more and more users have no idea what a terminal, commandline, shell, etc is..)
(iv) and (v): why hide power user options? The whole thing is hidden for the average user anyway.
(i) granted, but this doesn't suggest that the application couldn't be perhaps put elsewhere. I'm not sure where yet myself. A strong point against my argument, sure. But to address a few of the others:
(ii) please give me an example of the said application.
(iii) really doesn't work at all. Partly because I've never seen someone struggle to find a terminal, but also of course because it would be plain silly to get a new user to familiarise themselves with using the run dialogue to always start up a terminal. If the terminal's hidden (which it isn't at all), then we should make it more visible and accessible, not create a duplication of effort around when there's no clear need at all.